MACD 5 (Alt)

home *** CD-ROM | disk | FTP | other *** search

/ MACD 5 (Alt) / MACD 5.bin / workbench / wb / czesc_2 / memmometer / mm.doc < prev next >

Wrap

Text File | 1992-11-06 | 24.7 KB | 407 lines

/* * Information for MM Version 2.40, 11-Oct-1992 * * MemMometer - A program hacked from Tom Rokicki's WFrags more or less... * (in fact, a heck of a lot) in the style of Peter Da Silva's "Gauge." * The program opens a narrow window with the same dimensions as the disk * capacity gadget found in the top-level workbench window for an Amiga * DOS v1.3 floppy volume. The sizing gadget is like the one in Gauge; * to resize the window, just click the left mouse button over the "E". * The "F" is the program title in this rather short manifestation of * an Amiga Intuition window drag bar. * * My bin copy of Gauge broke when I put a Michigan Insider in my A1000. * I did not have source for the Gauge program, so I conjured this one. * To my chagrin, MM 1.0 broke when I got a 2000 (more on that shortly), * the Amiga 3000 blew away the previous version of this program, too, * of course. But that's the way it is with hardware-oriented software * hacks! :-| Changes with this version include an ARexx Port to allow * greater flexibility in setting the menu items than is provided by the * menu items alone, and rearrangement of the menus for A3000 and A4000 * memory spaces, plus code to keep the menu driven choices from kicking * the Enforcer. Please note that Amiga DOS allocates A3000 memory space * in heap fashion (autoconfiguring memory in successively lower addresses * starting from the top, while utilizing it within each zone in the usual * fashion from the bottom up). The following table describes how to set * MM for various Amiga 3000 and 4000 motherboard memory configurations: * * Fast Ram Size Base Address * 1 Meg 7f00000 * 2 Meg 7e00000 * 3 Meg 7d00000 * 4 Meg 7c00000 * 6 Meg 7a00000 * 8 Meg 7800000 * 10 Meg 7600000 * 12 Meg 7400000 * 14 Meg 7200000 * 16 Meg 7000000 * * MemMometer may be started from an icon, a CLI, or the Run command * from a CLI. MM uses dynamic allocation for its display data, and * does its own resource tracking. MM will surrender any resources * which it has successfully obtained from allocation requests if, * while MM is running, requested resources are denied. This type * of fault (exit code 20) proceeds silently, and without any notice. * * Now for a run through MemMometer's menu mechanics. MemMometer opens * with a non-interlaced-screen-height narrow window at the left side of * the Workbench screen. The window width is the same as the width of the * capacity gauge which Workbench used to render at the left side of the * v1.3 top level window for a floppy volume. As with Peter Da Silva's * original gauge program, the MemMometer has an E at the bottom of the * window, and an F at the top. * * The E and the F are respectively, the window sizing gadget, and the * window titlebar. While MemMometer can and does automatically arrange * the window to suit the memory configuration, it depends on the user to * select appropriate memory size and address values via the menus. The * menu style is the usual Amiga Intuition menu set; selection is achieved * by clicking the left mouse button while the mouse pointer is anywhere * within the program's window boundary, and then activating the menu bar * by holding down the right mouse button and sliding the mouse pointer * along the Workbench screen title bar at the top of the Workbench screen. * * At the left side of the Workbench screen title is the Project Menu. The * Project Menu has three options. The first option is "Front", which is a * window-to-front command for the event that the MM window was partially * buried by the opening of new windows after MM was invoked. If the * right mouse button is released while the mouse pointer is directly over * the Front menu item, the MM window will oblige by popping forward to an * unobstructed view. The second menu option is the "Back" item, which * will move the MM window back behind any other windows that have been * opened on the Workbench screen (with exception of a backdrop window). * The third Project menu option is the "Quit" option, which directs MM to * close its window and release the AmigaDOS resources it has allocated. * The normal return code is zero. * * The second Intuition menu is the Setup menu. There are two Setup menu * items. The first item is the "Mode" item. MM has two modes, and they * are selected by sliding the mouse pointer straight down from the screen * title bar over the Mode item , and then moving the pointer to the right * as the mode submenu is activated. The activated submenu provides two * choices, "Frags" and "Warps". Frags are rather much the same as they * were in Da Silva's gauge program. "Frags" is the default menu selection * with which MM is first initialized. The Frags display is described in * the following table: * * 2-Color Workbench 4-Color Workbench 8-Color Workbench * Unallocated Dark Gray Light Gray Light Gray * Allocated Black Medium Blue White * Fragmented Dark Gray Dark Gray Dark Gray * * Unallocated memory is free memory available to programs. The programs * may obtain this memory from AmigaDOS through allocation requests. The * Allocated memory is memory assigned to programs running under AmigaDOS. * Fragmented memory consists of interleaved small memhunks, some of which * are assigned to programs and some of which are in the free memory pool. * The smallest fragments are 8 bytes, and the largest memhunks may be more * than a megabyte. The fragmented class is assigned when, in making the * MM window display, a single horizontal pixel line was found to represent * both allocated and unallocated memhunks. For this reason, for a full * window height MemMometer, the resolution of the fragmentation is shown * in more detail on Amiga Workbench screens with the largest vertical * pixel count. * * The second mode item selection is the "Warps" mode. While the Frags * mode is usually utilized as a low-priority background indicator, the * Warps mode is usually utilized at a somewhat higher priority for the * purpose of tracking bugs and system irregularities. In this context, * I define warps as a form of discretized sample-to-sample differencing * function for some arbitrary segment of memory. Warps are determined by * dividing the selected address space evenly among the MemMometer display * pixels, computing an assignment checkfunction for each pixel line of the * display on the associated assigned memory space at some sample time, and * then, while retaining the previous pixel-by-pixel record, repeating the * same evaluation the second sample time and comparing the sequentially * determined checksums. A "checksum" is computed by means of a sequential * bit-wise eXclusive OR assignment. This type of checksum can readily * detect zeroed or changed values. In the table below, logical FALSE is * zero, logical TRUE is taken as 0x ffffffffffffffff and VALUE is then * anything else. Colors indicate the type of change. Colors for the most * part follow the v2.0 standard CBM workbench color set: * * Pen # Color Pen # Color * 0 Gray 4 Blue * 1 Black 5 Magenta * 2 White 6 Cyan * 3 Med Blue 7 White * * As this color table has two white values, some displayed information * will not be visible. This problem can be overcome by setting Pen # 2 * to a gray pen with RGB 13,13,13. For the v2.0 workbench, the standard * colors are rather much too drab to allow MemMometer to be used as a * diagnostic tool, but one can readily choose a more useful palette such * as the Day8Color.pre or the Night8Color.pre file included in the MM2.40 * distribution. The Day and Night presets are similar, except the day * palette uses brighter gray colors rather than the darker blues used in * the night palette. The night palatte has the least flicker for use of * interlaced displays. For the Night presets, the pen colors are: * * Pen # Color Pen # Color * 0 Medium Blue 4 Green * 1 Dark Blue 5 Cyan * 2 Light Blue 6 Yellow * 3 Red 7 Orange * * These colors are used to map the changes in memory content from sample * to sample as programs multitask together: * * Condition 2-Color Workbench 4-Color Workbench 8-Color Workbench * * VALUE ===> VALUE Medium Blue Medium Blue Medium Blue * VALUE =/=> VALUE Dark Blue Red Red * FALSE ===> FALSE Medium Blue Light Blue Light Blue * FALSE ---> VALUE Medium Blue Red Orange * VALUE ---> FALSE Medium Blue Dark Blue Cyan * TRUE ---> FALSE Medium Blue Light Blue Yellow * TRUE ---> VALUE Medium Blue Light Blue Yellow * TRUE ===> TRUE Medium Blue Medium Blue Green * FALSE ---> TRUE Medium Blue Medium Blue Green * VALUE ---> TRUE Medium Blue Medium Blue Green * * The second Setup menu item is a Frequency selection submenu. While the * selected value does set a minimum frequency with which the memory state * will be examined, it's done by introducing a delay between measurements. * The introduced delay will be equal in seconds to the value selected in * the submenu. The delay is accomplished by the AmigaDOS timer.device * using the VBLANK mode. Delay intervals of 1, 2, 5, and 10 seconds are * available from the menu. * * The third Intuition menu is a Priority menu. This menu applies only to * the MemMometer program and its associated CLI process. Initially it is * at priority 0 with the expectation that the user will set it lower once * the program is running, in order to give more time to the other active * processes the user will be running. A value of -50 is recommended. In * the event the Priority of MM is changed via the menu, the CLI inherits * MemMometer's new priority and retains that priority even after MM quits. * Thus, with extreme priority settings, it may be better to "Run MM" to * keep from passing the extreme priority to subsequent processes spawned * from the CLI that was used to invoke MemMometer. Also, go easy with the * positive priorities; remember that with AmigaDOS version 2.0 the DOS * input.device runs priority 20, the SCSI bus handler is 12, SCSI.device * is 11, FileSystem is priority 10, and the CON: and trackdisk.device * are priority 5 usually. Note that the first three MemMometer menu * items are used to increment or decrement a priority selected in the * lower part of the menu. Selection of the "NORM" menu item removes any * increment or decrement previously set while at any given level. * * The remaining Intuition menu selections are provided so that the range * and base address of the memory examined may be adjusted for the user's * Amiga memory configuration. Note that for chip mem, at least, the base * address must always be set to the correct base address for the given * memory configuration in order for the Frags option to work properly, * but that the range may be adjusted to give a better resolution for the * first segments around the base address, if desired. Menus are provided * for Chip memory, the old Slow-Fast (C00000/Ranger) memory, and Fast * memory. While I have had no difficulty as a result of selecting a * range of memory that involved a non-existent seqment for Chip or Fast * memory in either Frags or Warps mode on an A1000, when I selected some * non-existent SFMemory on my Fat Agnus Amiga 2000 in Warps mode, it * caused a total system-wide red Guru 4 (illegal instruction exception). * * After that, I decided to post a requester to notify the user tersely * that a crash is _possible_ with incorrectly specified menu selections * the in warps mode. Since it is possible, for example, to roll over * on 24-bit addresses via large memory size menu selections, one can * access forbidden zones through inappropriate settings of the Fast Mem * menus as well. Thus MM also calls the requester if the Fast Mem size * menu is changed. The requester displays the message: * * WARNING! CRASH POSSIBLE * MENU MEMORY SELECTIONS MUST * REFERENCE EXISTING MEMORY * * Risk It Retreat * * You don't have to worry about a crash if you really have an amount of * SF or Fast memory equal or greater than the amount you specified and * the base address is within what you specified (the default base address * for SF Mem is C00000 and 200000 for A2000 Fast Mem). Too bad I had to * do this, but it is a matter the hardware regards seriously, as some * registers do things when they are read, never mind what they do when * they are written! Of course, the program could be re-written to use * the autoconfig mem list to identify all valid segments of the memory * but then that would lessen its value as a snoop tool for situations * involving poorly behaved autoconfiguration hardware. In this version, * though, requests for WARPS mode on chip memory with the base set to 0K * will result in a silently applied 1K offset in order to avoid Enforcer * hits. So now the problem will remain only with Mungwall, if it happens * to be set to be sensitive to reads on unallocated memory. * * So, here you see the two options. The left button says - Risk It -. * That's a comfortable gamble if you know your Fast memory configuration. * Pre Fat-Agnus Amiga 2000 machines have 512K of Slow-Fast memory. The * Newer 2000s have no C00000 Slow Fast memory, and the A3000 only has the * 200000 ZorroII 16-bit Fast Memory if you added a Mem card - so beware * of this and try the other settings when you have nothing else going on, * until you gain a knowledge of what is safe. The - Retreat - option sets * the SF or Fast Memory Size selected internal to the MemMometer program * to zero and clears the display. (It does leave the menu items checked, * though, so you will have to remember to re-select suitable menu values * in order to get the display to show something in each existing memory * type. For Chip and Fast memory this will simply entail going back into * the menu and again selecting whatever was previously checked. The SF * memory size should be set either to appropriate values or to "NONE".) * * Note that in the display there may at any time be anywhere from one * to three MemMometers - for Chip (left-hand column), another for the * Slow Fast mem (center column) and yet another for Fast mem (right-hand * column). These MemMometers can be turned on or off as desired by * selecting "NONE" or the various items in the Size menus. * * With Version 2.40, ARexx is available via Tom Rokicki's MinRexx program * as a compling option. It has been included in the V2.40 compiled code. * by invoking a rexx shell script via the "rx" command, the user can set * the menus to any value allowed within the MemMometer program's coded-in * ranges. Note that the "Enforcer" address avoidance code built in with * this version for the menus is not applied to address and size values * invoked from ARexx scripts. It is thus up to the script writer to be * sure that chip mem addresses below 1K are what the user wants to see. * Any so-invoked address below 1K will otherwise no doubt get a response * from the Enforcer program. Sample ARexx scripts have been included in * the V2.40 distribution for each menu item. Note: the first instance of * a mm executable invoked has the ARexx address "mm1", the second will be * "mm2", etc. Up to four instances are allowed by the code in V2.40 - * You'd have to be some sort of prevert to want to run more than four * copies of this program in any Amiga, and you may have to be downright * looney to want to run even one copy for any longer than it took to find * out what was wrong with the hardware or software under test. But you * can do it if you write the scripts to drive it. I am grateful for, and * do wish to acknowledge the assistance via Usenet of Vince Herried and * Dan Barrett, two programmers who sent me email advice on how to get * minrexx going in general, and how to handle multiple invocations of the * program, in particular. Without their help, revision to V2.40 would * have been longer in debug and test by probably quite some time. And of * course, without Tom Rokicki's MinnRexx program (included in the codes) * it would have been impossible for one of my experience and intellect * to do this sort of thing at all (but you could tell that from looking * at my code, right?). But I can say that my efforts in coding the * MemMometer program have survived three versions of AmigaDOS upgrades * without any major blow-up from that (the hardware already having been * forgiven). Though it may be that this is more to the credit of the * Amiga operating system software designers than it is to any effort on * my part. * * Parts of several freely distributable programs have been used to make * MemMometer. Menus, for instance, are done in the style VT100 (Wecker, * et al). As with the VT100 program, MemMometer has preset variables. * As mentioned, the program now has an AREXX interface with which to * automatically set the variables. I actually did get the code written * for that this century! * * MemMometer uses forbid() and permit() when it examines the mem list in * Frags mode. I suppose it is possible with large amounts of memory to * scan, that some gross treachery can happen while the list is locked. * However, neither my 6 meg Amiga 2500 nor my 4 meg Amiga 3000 seem to * have any problem with it. It takes a while after startup to settle * and display the large byte counts associated with Fast mem, so try to * be patient... MemMometer is most useful for finding out why large * programs won't load. It's also useful in development for seeing the * impact your application is having on memory fragmentation, or how * various programs (and viruses, for that matter) are allocating memory. * * The Warps mode displays any change it sees in memory from one sample * to the next; BUT this mode only works sensibly when JUST ONE memory size * selection is active (set others to "NONE"). The memory space is scanned * asynchronously, so it can have sample alias difficulties. However, the * Warps mode does not use forbid(), permit(), enable(), disable(), or any * other constrictive system call. It just does a lot of read-only memory * cycles and writes the result in its own dynamically allocated memory * space. * * To run MemMometer, simply type * * run MM * * or click on the icon. * * Then open the menu item selections and set them for your configuration. * Frags mode, and 512K of CHIP @0 is the default these days, what with * hugh variety of configurations routinely encountered. The modes are * are color coded into the "F" and "E" indicators in accordance with the * AmigaDOS 2.0 color table: * * Mode Indicator 2 color WB 4 Color WB 8 Color WB * * Frags E Medium Blue Light Blue Medium Blue * Warps E Medium Blue Red Orange * * One column: * Chip F Medium Blue Medium Blue Medium Blue * Slow-Fast F Medium Blue Light Blue Light Blue * Fast F Medium Blue Medium Blue Green * * Two columns: * Chip +SF F Medium Blue Light Blue Light Blue * Chip +Fast F Medium Blue Medium Blue Green * SF + Fast F Medium Blue Light Blue Yellow * * Three columns: * C + SF + Fast F Medium Blue Light Blue Yellow * None F Medium Blue Medium Blue Red * * The source code included with this distribution was compiled with the * Manx Aztec C compiler, version 5.2a in 32-bit integer mode. Numerous * type casts in the code, as well as other non-alignments with the Lattice * environment would make compilation under versions of Lattice difficult. * Sorry. Compilation instructions are of course in the makefile included * in the distribution. Version 2.39 of this program, which is does not * include the ARexx code, can be compiled in 16-bit integer mode on any * version of the Manx Aztec C compiler from 3.6 through current versions. * the files makefile2.39 and makefile2.30 are provided in the version 2.4 * distribution for this purpose. * * About my part of C code - it wasn't done for speed, as I am sure you can * tell. If I wanted speed I would have used assembly language. It also * likely isn't elegant code, by a long shot (unless it's the part I got * from Rokicki's WFrags). But assembly language is time-consuming to * write, so that won't happen any time soon. With V2.40 I've done the * promised ARexx port. I can see that it needs a "Hold", "Cycle", and * "Release" command set to allow better synchronization with other active * processes under debug proceedings. And perhaps the next version can do * away with the horrors of the fast memory address menu via some proper * utilization of the system mem lists. Gross comments about the code, or * bug reports may be e-mailed to me at the site domain specified below. * The last release version (2.20) DID have some bugs (two addresses in the * fast mem menu were a factor of a hexadeciment off). Nobody reported any * of the bugs, but I assume that's because either the program is totally * worthless to any practicing professional and so irritating to everyone * else that they didn't bother with reporting anything, or that since they * had the code they just fixed the bugs or patched the executable and kept * on truckin'. * * About everyone else's C code in MM - Let's see, VT100 (Wecker et al) has * been freely distributable since the early days of the Amiga. When VT100 * was first posted, Wecker did not prepend a copyright to the code. He * later discovered that his employer (DEC) routinely required employees to * sign a contract statement which granted to DEC all rights with respect * to codes written by DEC employees, whether the codes were written on the * company's time/facilities or otherwise. I do not know how the matter * was resolved, but VT100 still seems to be on the freely distributable * software list. The menus in MM, while styled with the same code forms * as were used with VT100 v2.3, are of course different in content in any * case. The WFrags program was, I believe, a version by Tom Rokicki (the * Amiga Tex guy) might be evolved from the Frags program originally put * to the net by Mike Meyer. WFrags was submitted to the net without a * prepended copyright notice, evidently intended as freely distributable * software. * * The spirit of these contributions is that they are not to be used for * commercial purposes, and the original authors certainly appreciate * being cited for their work. So I just did that. The timer codes are * exerpted from a network article by Andy Finkel of CBM, submitted as a * demonstration of the ease of implementing the Amiga timer.device in C. * * So, for my part, I add no further restrictions to the codes in MM. * In that spirit, I hereby submit the following Standard Disclaimer: * * The authors accept no responsibility for anything either beneficial or * detrimental that may happen as a result of using the codes in MM. The * codes are intended for non-commercial use only. * * * Howard Hull hull@ncar.ucar.edu * */